The present invention relates to improving the performance of computer software programs, and more specifically, to analyzing the performance of a program that is executing in the field.
A common way for software developers to analyze the execution of a program they are developing or modifying is to run the program on a “debugger” tool that allows them to set breakpoints in the code and to create a trace of the execution of the code. Such tools are used in the software development lab to test and debug programs. An additional way to analyze the execution of the code is to insert statements within the code itself that take some action to allow the programmer to later determine how the code was executed, such as by writing a value to a memory or printing a value whenever that statement is executed. Such may be referred to as a “debug” statement, although they can be used to analyze performance issues that may not be bugs. An example of a debug statement may be a portion of code that causes a value to be printed every time the particular code segment (or function) to which the debug statement is attached is accessed during operation of the code. Traditionally, debug statements in a software program (often referred to herein as code) are assigned a level which indicates the importance of the statement and a component. A debug level for the program is assigned at compile or run-time, and the statements of that importance or higher are output when the program runs.
For example, suppose there are levels—TRACE, DEBUG, and ERROR. TRACE is the least important, and ERROR is the most important. If the debug level is set to ERROR, then only ERROR debug statements will be output. If the debug level is set to TRACE, then all debug statements will output. Even if they do not trigger an output, such debug statements have some impact on the execution speed for the program because the execution of the debug statements themselves costs cycles, and thus debug statements are used judiciously. By contrast, debugging in the lab using a debugging tool that creates its own external trace does not impose the performance cost into programs running in the field.
If the debug level is set at compile time, then changing the debug level involves recompilation which is inconvenient and in many situations impossible. For example, consider a running program that encounters a slowdown or other performance reduction and, thus, may need to be debugged. In some instances, the running program may be mission critical and cannot (or should not) be turned off If the program cannot be turned off, it cannot be recompiled and, thus, debugging can be difficult.